Resolves #67380

Changes

This PR primarily makes changes to the server-side SavedObjectsRepository (SOR) and SavedObjectsClient (SOC) methods.

1. Added new SOR/SOC methods:

• collectMultiNamespaceReferences -- Given an list of object types/IDs, this will collect all outbound multi-namespace references (including transitive references) and return them. It also checks for legacy URL aliases in other spaces and includes that information in the result.
  • Public API route: /api/spaces/_get_shareable_references
  • Note: this is not used by any consumers yet, it will be in a follow-on PR.
• updateObjectsSpaces -- Given a list of object types/IDs, spaces to add, and spaces to remove, this will update the spaces for each object.
  • Public API route: /api/spaces/_update_objects_spaces

I implemented a new approach for saved objects authorization in these methods. First we fetch the object(s) in question, then we check privileges for all spaces (including any spaces those objects currently exist in). This has the benefit of reducing the amount of privilege checks we need to make (we don't need an additional privilege check to redact object namespaces). This is an implementation detail that is not visible to consumers.

For collectMultiNamespaceReferences, if the user is not authorized to access a requested object, they will encounter a 403 error. If they are not authorized to access a referenced object, that will be silently filtered out of the results. This is consistent with our existing authorization checks for exporting saved objects with references. See unit tests and API integration tests for specific examples.

2. Removed outdated SOR/SOC methods:

I removed the addToNamespaces and deleteFromNamespaces methods, these are superseded by the new updateObjectsSpaces method. I updated existing client code in the "spaces" and "ml" plugins to use the new method.

3. Updated Copy-to-Space behavior

The copySavedObjectsToSpaces API has been improved for usage with multi-namespace types. Previously, if you attempted to copy an object to another space where it already exists, it would attempt to do so and return a conflict error. Then you would be able to resolve the conflict error by overwriting the same object with itself. While this technically worked, it was a confusing and poor user experience. Now if you attempt to copy object(s) to space(s) where they already exist, those will be skipped.

Note: we made a conscious decision not to do the same for resolveCopySavedObjectsToSpacesConflicts, as it's a lot of extra testing surface for less benefit. Technically one user could attempt a copy, then another user could share one of the affected objects to a destination space before the first user gets a chance to resolve the conflicts -- in this case, if the user had chosen to overwrite the destination object, it would be harmless and nothing would actually change.

What is not included

These will be addressed in a follow-on PR:

• Client-side changes:
  • Update ShareToSpaceFlyout to prevent users from sharing an object into a space where it has a matching alias -- this situation would cause future calls to resolve to result in an alias conflict scenario. Instead, at share time, the user must decide to skip the changes, or to disable the legacy URL aliases in the destination space(s).
  • Update ShareToSpaceFlyout to fetch outbound references, and to display references/tags, and give users the option to exclude tags from the share operation.
  • Update the "Delete" modal on the Saved Objects Management page to warn users if they are attempting to delete an object that exists in multiple spaces (it would result in a 400 error), and allow them to do it anyway using the force option
  • Update the client-side SOC implementation to support the resolve method -- this should have been done in Phase 2.5 but it was missed because it does not rely on the same type definitions as the server-side SOC
• API docs for /api/spaces/_get_shareable_references and /api/spaces/_update_objects_spaces in the new docs system
• API docs for plugin authors to provide guidance on converting single-namespace object types into multi-namespace object types
• Additional usage data collection for the resolve method (to track how many times legacy URL aliases are used in practice, and to track how many legacy URL aliases are disabled)

Testing

To manually test collectMultiNamespaceReferences functionality:

• Install this plugin: https://github.com/jportner/kibana-sso-test-plugin
  It registers the toy saved object type (which is shareable), and allows you to easily generate new objects for testing.
• Navigate to the plugin ("barney" in the nav pane) and click the "Get new toys" button to generate new objects.
• Navigate to the Saved Objects Management page and use the Share action on any of the objects
• "Sheriff Woody" is a special case, it has aliases in the "alpha", "bravo", and "charlie" spaces. If you look at HTTP responses in dev tools, when you open the Share flyout for this object, you will notice that the _get_shareable_references API returns a list of spaces where this object has conflicting aliases.
  • Note: you don't need to have actually created these three spaces for the purposes of this test -- but you can manually create each matching space (before or after) if you want. At the moment it will have no visible impact.

To manually test updateObjectsSpaces functionality:

• Spin up Elasticsearch and Kibana with a trial license
• Create additional spaces
• Add sample data
• Use the ML app to create jobs with the sample data
• Use the ML job management page to share the jobs to other spaces